FYI, this is one of the patterns that we likely want to make easier with pytest ethereum (as suggested by @fubuloubu ), could just be a very thin wrapper around pytest.raises to start with but something like:

import pytest_ethereum as pte  # we should establish a convention, don't know if I like this one

with pte.tx_fail():
    ...

TransactionFailed could also be a "default" for such a wrapper (that can be overridden)

@fubuloubu like this idea - but i'm also partial to explicitly writing the exception name. i.e. tx_fail. in which case if you want to override it, you could just use pytest.raises(xxx) - or am i missing something? can you give an sample api of what you were thinking?

Same here, another pattern we want to make easier (as suggested by @fubuloubu )

Here are some ideas for starting points.

# test specific log
log = ...
assert Log(registry.events.Release, "package", "1.0.0", "google.com").match(log)

# or maybe test it is just present in a receipt
receipt = ...
assert Log(registry.events.Release, "package", "1.0.0", "google.com").is_present(receipt)

# or test that there is no log entry
assert Log(registry.events.Release, "package", "1.0.0", "google.com").not_present(receipt)

The Log constructor would need to do some magic introspecting the ContractEvent object returned by registry.events.Receipt but I think all the necessary information is there.

Very curious what the vyper pattern would be to allow arbitrary numbers of releases. Can we just use an arbitrarily large number here instead of 128?

Wanted to work on a stack widget, which could solve this. Constant time insertions and accesses. Still not sure if it should be a full double-linked list ($$$ gas) or a very simple push/pop data structure with no ability to pop anything other than the end.

@njgheorghita (maybe @jacqueswww or @fubuloubu can confirm)

What about this API which is in the vyper by example section:

https://vyper.readthedocs.io/en/latest/vyper-by-example.html#crowdfund

package_ids: {id: bytes32}[int128]

Wouldn't that allow you to have an effectively infinite psuedo-array of them?

Also, I assume it should be possible to do a mapping to a non-object type such as int128 => bytes32 but it wasn't clear what that syntax would be...

Yup, that would be the most efficient possibility. You would have to manage a separate "length" parameter to keep track of what the last entry you set was though.

A stack type widget could manage that for you under the hood. Same with a queue type.

I assume this is how you make this compliant. I'd be curious if there's a way to loosen the restriction such that length <= 5. Doesn't have to block you moving this forward.

You can return fixed arrays I think. You can definitely return bytes[160], if not bytes32[5]